The Virtual Router Redundancy Protocol (VRRP) provides for the implementation of a redundant IP interface to be shared between two or more routers on a common LAN segment. VRRP is described in IETF RFC 2338. VRRP allows you to provide alternate router paths for a host without changing the IP address or MAC address by which the host knows its gateway. The use of virtual routers, or abstract objects that may include one or more physical routers, enables failover redundant routing in the event a master router fails due to non-availability or another type of event. However, the existing protocol suffers from various limitations.
In VRRP control and management abilities (e.g., the ability to respond to ICMP ping, TCP connection requests, etc.) are limited to owner routers. Routers are classified as owners and non-owners, where owners “own” an actual IP address for the interface or gateway to a LAN, WAN, MAN, LAN segment, etc. This means that only owners may respond to management-oriented protocols such as ICMP ping. If the owner router fails, is taken out of service, or otherwise becomes unavailable, then no router, including a non-owner router that takes over as the master router for the virtual router identifier (VRID) with which the IP address used for the virtual router is associated, will respond to management-oriented messages, such as those used for testing connectivity (e.g., ICMP Ping). If a backup non-owner router is assigned as the new master router, it will not respond to messages sent to the IP address associated with the virtual router identifier for which it has taken over as master because that IP address is an actual interface only on the owner. Thus, system and network administrators are unable to gather information as to whether a particular gateway has connectivity. More problematic is the master selection process specified in VRRP.
VRRP does not specify events or conditions that determine how a master is selected from non-owner routers. When a master router fails, VRRP provides for the next specified non-owner router to become master. However, this fails to take into account events or network conditions that could affect whether a particular non-owner router is better suited to become master over another. This may lead to the inefficient selection of backup non-owner routers as master routers.
Thus, a solution is needed for an improved virtual router redundancy protocol for selecting a master router. Additionally, a solution is required that enables master router selection based on criteria such as availability and priority.